Cumulated content of Working Group Meeting from 2023

Working Group meeting

Date: 16/05/2023
Participants: Natalie Muric, Pietro Palermo, Peter Borresen, Thomas Pettersson.
Model editor: Andreea Pasăre
Note editor: Jana Ahmad

Agenda

Harmonization of modules for eCatalogue, eFulfilment, and eOrdering Modules

  • Charge Information - Item Level or Line Level?

  • Item and Batch IDs

  • Organisation and Person Certificates

  • Remodelling epo-ord:DeliveryTerm

Discussion

The working group began by reviewing previous agreements related to eCatalogue, eOrdering, and eFulfilment modules reached in meetings held on April 25, 27, and May 3, 2023.The participants confirmed their consensus on the proposed changes.

  • Removal of epo-cat:hasExternalSpecification property in the epo-cat:item in Catalogue module

  • Standardised namespace prefix for ePO Model (Note: in the text and diagrams in this report the standardised namespace of epo: has not been used as the standardized namespace is to implemented with all other changes.)

  • Renaming epo-cat:ItemDescription to epo:ItemProperty.

  • Replacing epo-ful:hasBaseAmount property with epo:isCalculatedOn in epo-ord:AllowanceChargeInformation and epo-ord:TaxInformation . Replace epo-cat:specifiesItem relationship between epo:Deliverable and epo-cat:Item by inheritance of epo-cat:Item by epo:Deliverable.

  • epo:Contractor and epo-ord:Seller are the same concepts in a Public Procurement.

  • epo-ord:AllowanceChargeInformation will have 3 subclasses: epo-ord:AllowanceInformation, epo-ord:ChargeInformation, and epo-ord:PriceDiscountInformation, because epo-ord:AllowanceChargeInformation is an epo-cat:InformationHub, and it is directly connected to the Line and Document.

  • The VAT rate value will be modeled through epo-ord:TaxInformation epo-cat:hasPercentage and epo-ord:TaxInformation epo-cat:hasTaxCategory. The working group then continued to discuss the points that were seen as contentious previously:

Charge Information - Item Level or Line Level?

During the discussion, participants debated whether the Charge Information should be at the Item level or Line level. To illustrate the point an example of countries where certain charges are associated with food items containing sugar. For instance, if an item is priced at 1 euro, the actual amount paid might be 1.7 euros due to the sugar charge. This charge is applied at the price level.
One suggestion put forward was to have the price at the item level, establishing a direct association between the item and its price. However, after further deliberation, the decision was made to maintain the price at the line level while establishing a reference between the line and the item.

Z

In PEPPOL the price is specified based on the location, and the order reflects the price based on quantities. There are two types of discounts: line-level discounts and price-level discounts. Line-level discounts can be defined as a specific amount per line, such as a discount of 100 euros per line. Price-level discounts, on the other hand, are expressed as a certain amount per unit, such as cents per orange.
As a result of the discussion, it was decided to remove the epo-ord:PriceDiscountInformation element and introduce new associations for enhanced clarity and consistency. The new associations are epo-ord:hasPriceDiscountInformation between epo-cat:Price and epo-ord:isSpecificToOrderLine, as well epo:hasPriceSurchargeInformation between epo-cat:Price and epo-cat:ChargeInformation.

wPimct8g2PsZAAAAABJRU5ErkJggg==

Modeling of Item and Batch IDs

The participants agreed to replace the relation adms:identifier with epo:hasBatchID to improv clarity and consistency. The epo: hasCatalogueItemID is replaced by epo:hasSellerItemID
As part of the discussion, it was agreed to add definitions for all epo:Item and epo:Batch IDs:

  • epo:hasManufacturerItemID: The general identifier assigned to the concept as defined by the manufacturer.

  • epo:hasBuyerItemID: The general identifier assigned to the concept as defined by the Buyer.

  • epo:hasBatchID: The identifier assigned to a specific batch of the produced Item.

  • epo:hasSellerItemID: The general identifier for the concept as defined by the seller.

  • epo:hasSerialID: The identifier assigned to the specific instance of the produced concept.

d7HXMJBwO4wAAAABJRU5ErkJggg==

To illustrate these concepts, an example was discussed: when purchasing a new mobile phone, the seller ID and the manufacturer ID may differ, but a generic buyer ID would be used.
Organisation and Person Certificates
It was agreed upon by the participants to introduce the epo:hasCertification relation between epo:Certificate and epo:Organization, epo:Person, and epo:Item. This new relation allows for the association of certifications with these entities.
Furthermore, the definitions for the following concepts were updated as follows:

  • epo:Certifier: A Role of an Agent that issues a Certificate.

  • epo:Certificate: Proof of conformance of the instance of the concept to a defined set of criteria, ensuring credibility, trust and transparency.

uVf8P8DpJtvtO1sOf4AAAAASUVORK5CYII=

Remodelling epo-ord:DeliveryTerm

During the working group meeting, it was agreed by the participants to rename the entity epo-ord:DeliveryTerm to epo-ord:DeliveryAgreement. By changing the name of the concept there is no conflict with the Term hierarchy of the ontology and the original modelling can be reused. The update was made directly in the meeting.
.

Dt6P7F1hhjhgYAgMUgfAEAANjUhC8AAACbmvAFAABgUxO+AAAAbGrCFwAAgE1N+AIAALCpCV8AAAA2NeELAADApiZ8AQAA2NSELwAAAJua8AUAAGBTE74AAABsasIXAACATU34AgAAsKkJXwAAADY14QsAAMCmJnwBAADY1IQvAAAAm5rwBQAAYFMTvgAAAGxqwhcAAIBNTfgCAACwqQlfAAAANrUkfI0xxhhjjDHGmM020f8H9pztfcNmz7AAAAAASUVORK5CYII=

Revising Definitions

The participants revised the definitions with respect to the concepts that were discussed during the meeting.

  • epo-ord:DeliveryAgreement: Term applying to the delivery of goods, services and works. Additional Information: Delivery terms identifier can normally be Incoterms accompanied by the description of specific conditions related to the delivery.

  • epo-cat:InformationHub: Grouping of data that may be associated to various concepts. Additional Information: For example, AllowanceChargeInformation may be associated to the Order or the Catalogue (either at the Line level or at the Document level), amongst others.

  • epo-cat:ChargeInformation: Information about tax, fee or duty imposed. Additional Information: Charge category indicates the nature of the tax/duty/fee, for example VAT, CAR, etc. Charge category modifier may be used in case different levels, exemptions or other modifications apply. The charge can be fixed or relative to the price.

  • epo-ord:AllowanceChargeInformation: Information about discounts, taxes, duties and fees imposed.

  • epo-ord:AllowanceInformation: Information about the discounts imposed.

Action Points:

  • Remove epo-ord:PriceDiscountInformation and introduce new associations:

  • epo-cat:Price epo-ord:hasPriceDiscountInformation epo-ord:isSpecificToOrderLine

  • epo-cat:Price epo:hasPriceSurchargeInformation epo-cat:ChargeInformation.

  • Update definitions for all epo:Item and epo:Batch IDs

  • Organisation and Person Certificates:

  • Update the definition of epo:Certifier and epo:Certificate.

  • Introduce new associations:

  • epo:Person epo:hasCertification epo:Certificate

  • org:Organization epo:hasCertification epo:Certificate

  • epo:Item epo:hasCertification epo:Certificate

Working Group meeting

Date: 04/05/2023
Participants: Natalie Muric, Peter Borresen, Thomas Pettersson
Model editor: *Andreea Pasăre
*Note editor: Jana Ahmad

Agenda

Goal: Discuss the current status and any potential improvements/harmonisations needed for the eCatalogue, eFulfilment, and eOrdering modules.

  • Discuss removing "postAward" objects and considering them as a document.

  • Also, consider "epo-cat:announcesPostAwardObject."

  • Revise "epo-cat:hasExternalSpecification" property in the "epo-cat:item" object and consider deleting it since we have added "epo-cat:hasExternalSpecification" association between "epo-cat:Item" and "epo:Document."

  • Change eCat:Item to epo:Item

  • Discuss adopting "epo" as a uniform namespace prefix in the ePO model.

  • Revise the naming of "epo-cat:ItemDescription" to align it between modules.

  • Discuss aligning VAT and other tax categories between modules.

  • Propose using "TaxInformation" instead of "hasVATRate" and "hasVATCategory."

  • What is the difference between TaxInformationSchema and TaxInformation?

  • Discuss if "epo-ord:PriceDiscountInformation" and "epo-cat:ChargeInformation" are the same and align them across modules.

  • Propose changing "epo-cat:specifiesItem" to "epo:specifiesDeliverable."

  • Propose adopting "epo-cat:Deliverable" into all modules.

  • Discuss the difference between "epo:Contractor" and "epo-ord:Seller" for all modules.

  • Decide whether "epo:hasSerialID" should be at the Item level or the Batch level.

  • A party should have authorization. This needs to be modeled. Take into account the Certificate as well.

  • Discuss epo-ord:TaxInformation definition.

  • Discuss removing epo-ord:DeliveryTerm.

  • Discuss the proposal to change epo-cat:ItemDescription to 'epo-cat:ItemProperty

  • Considering the possibility of moving 'TaxInformation' to 'epo-cat:Item', but further investigation is required

  • What is the Difference between epo:hasManufacturerItemID and epo:hasSerialID

Discussion:

  • The participants has approved the removal of the "postAwardObject" class and instead considers "postAward" objects as documents for the eOrdering, eCatalogue, and eFulfilment modules.

  • The participants approved to Remove "epo-cat:hasExternalSpecification" property in the "epo-cat:item" in Catalogue class

  • The participants has agreed upon the use of 'epo' as the standardized namespace prefix in the ePO model.

  • The participants has approved changing from 'epo-cat:ItemDescription' to 'epo:ItemProperty'

  • The participants approved that "epo:Contractor" and "epo-ord:Seller" are the same for all modules. However, it still needs to be determined how to incorporate this into the model."

  • epo:hasBatchId, epo:SerialId are different, and they are in Item instances. (TBD 16)

9k=

  • The participants discussed the need for parties to have authorization.

    • The relation between person and epo:Certificate should be added

9k=

  • The participants discussed removing if removing epo-ord:DeliveryTerm​ will affect eFulfulment model.

    • epo:hasGeneralDeliveryTerm​, epo:hasDeliveryTermDescription​ ​ properties will be added to epo-ord:DeliveryInformation

    • epo:specifiesDeliveryTermLocation​ relatin will be added between epo-ord:DeliveryInformation and dct:Location

9k=

  • The participants discussed the ReceiptAdvice

  • There are three type of rejection for recipet

  • In ReceiptLine livel

  • In Consignment Delivery Shipment.

  • TransportHandlingUnit

Action points:

  • "epo:Contractor" and "epo-ord:Seller" are the same for all modules. However, it still needs to be determined how to incorporate this into the model.

  • ReceiptAdvice modeling in eFulfilment epic

Working Group meeting

Date: 02/05/2023
Participants: Natalie Muric, Ivan Willer, Sellitto Giovanni Paolo
Model editor: *Andreea Pasăre
*Note editor: Jana Ahmad

Agenda:

  • Review Criteria model modifications

  • Review Channel and Contact Point

  • Review Place of Performance: GH 364

  • Review metadata requirements for RDF notices

Discussion:

The WG discussed the Criteria model for standard forms and eforms mappings.

wO0qaylAYlMjAAAAABJRU5ErkJggg==
tLyNyjxhMIAAAAASUVORK5CYII=

  • at-voc:applicability codelist has been relocated from epo:ParticipationCondition to epo:Contract.

  • A model for instantiating selection criteria has been created to map the conditions for participation and conditions related to contract in a standard form.

ajAAAAABJRU5ErkJggg==

  • To ensure that ePO mode meets the requirements for pursuing professional, economic, and technical abilities in the standard form, the epo:ProfessionalSuitabilitySummary, epo:EconomicStandingSummary, and epo:TechnicalAbilitySummary objects have been added to the epo:SelectionCriteriaSummary.

  • The objects epo:ProfessionalSuitabilitySummary, epo:EconmicStandingSummary, epo:TechnicalAbilitySummary are added to epo:SelectionCriteriaSummary to meet suitability to pursue the professional, economic standing and technical ability requirements in the standard form.

  • The properties epo:hasSelectionCriteriaStatedInProcurementDocuments and epo:describesMinimumLevelOfStandards have been added to the epo:SelectionCriteriaSummary object to address the economic and financial standing requirements.

H+gQmT5NYBKCAAAAAElFTkSuQmCC

  • The properties epo:describesProfessionRelevantLaw and epo:hasServiceReservedToParticularProfession have been added to the epo:ProfessionalSuitabilitySummary object to provide a list and brief description of the relevant conditions that need to be fulfilled.

IGFi3pBDIuwAAAABJRU5ErkJggg==

  • The property epo:describesObjectiveParticipationRules has been added to fulfill the objective rules and criteria for participation requirement.

  • The property epo:describesDepositsAndGuaranteesRequired has been added to address the requirement for deposits and guarantees.

Y2EYhmG4V26jAGsYhmEYZm6jAGsYhmEYZm6jliysIQiCIGhYBFhDEARBUMsFWEMQBEFQywVYQxAEQVDLBVhDEARBUMsFWEMQBEFQywVYQxAEQVDLBVhDEARBUMsFWEMQBEFQywVYQxAEQVDLBVhDEARBUMsFWEMQBEFQywVYQxAEQVDLBVhDEARBUMsFWEMQBEFQywVYQxAEQVDLBVhDEARBUMsFWEMQBEFQywVYQxAEQVDLBVhDEARBUMsFWEMQBEFQywVYQxAEQVDL5cAahmEYhuF2+v8BvMGzjUNiBdUAAAAASUVORK5CYII=

  • epo:hasPaymentArrangementand epo:hasEPayment properties is in epo:ContractTerm which satisfy main financing conditions and payment arrangements and/or reference to the relevant provisions governing them.

  • epo:hasOrganisationGroupType is added to epo:ContractTerm to fulfil information abut staff responsible for the performance of the contract.

  • epo:hasReservedExecution in epo:Contract satisfies the execution of the contract is restricted to framework of sheltered employment programmes

Rjn6Ax2AAAAAElFTkSuQmCC

  • epo:describesDepositsAndGuaranteesRequired and epo:describesVerificationMethod: properties are added to the epo:ParticipationConditionsSummary object to satisfy Qualification for the system requirement.

Y2EYhmG4V26jAGsYhmEYZm6jAGsYhmEYZm6jliysIQiCIGhYBFhDEARBUMsFWEMQBEFQywVYQxAEQVDLBVhDEARBUMsFWEMQBEFQywVYQxAEQVDLBVhDEARBUMsFWEMQBEFQywVYQxAEQVDLBVhDEARBUMsFWEMQBEFQywVYQxAEQVDLBVhDEARBUMsFWEMQBEFQywVYQxAEQVDLBVhDEARBUMsFWEMQBEFQywVYQxAEQVDLBVhDEARBUMsFWEMQBEFQywVYQxAEQVDL5cAahmEYhuF2+v8BvMGzjUNiBdUAAAAASUVORK5CYII=

Working Group meeting

Date: 27/04/2023
Participants: Natalie Muric, Christian Mondini Consrzio, Ivan Willer, Pietro Palermo, Sellitto Giovanni Paolo, Wim Kok. Thomas Pettersson
Model editor: Andreea Pasăre
Note editor: Jana Ahmad

Agenda

Goal: Discuss the current status and any potential improvements/harmonisations needed for the eCatalogue, eFulfilment, and eOrdering modules.

  • Discuss removing "postAward" objects and considering them as a document.

  • Also, consider "epo-cat:announcesPostAwardObject."

  • Revise "epo-cat:hasExternalSpecification" property in the "epo-cat:item" object and consider deleting it since we have added "epo-cat:hasExternalSpecification" association between "epo-cat:Item" and "epo:Document."

  • Change eCat:Item to epo:Item

  • Discuss adopting "epo" as a uniform namespace prefix in the ePO model.

  • Revise the naming of "epo-cat:ItemDescription" to align it between modules.

  • Discuss aligning VAT and other tax categories between modules.

  • Propose using "TaxInformation" instead of "hasVATRate" and "hasVATCategory."

  • What is the difference between TaxInformationSchema and TaxInformation?

  • Discuss if "epo-ord:PriceDiscountInformation" and "epo-cat:ChargeInformation" are the same and align them across modules.

  • Propose changing "epo-cat:specifiesItem" to "epo:specifiesDeliverable."

  • Propose adopting "epo-cat:Deliverable" into all modules.

  • Discuss the difference between "epo:Contractor" and "epo-ord:Seller" for all modules.

  • Decide whether "epo:hasSerialID" should be at the Item level or the Batch level.

  • A party should have authorization. This needs to be modeled. Take into account the Certificate as well.

  • Discuss epo-ord:TaxInformation definition.

  • Discuss removing epo-ord:DeliveryTerm.

  • Discuss the proposal to change epo-cat:ItemDescription to 'epo-cat:ItemProperty

  • Considering the possibility of moving 'TaxInformation' to 'epo-cat:Item', but further investigation is required

  • What is the Difference between epo:hasManufacturerItemID and epo:hasSerialID

Discussion:

  • The WG has approved the removal of the "postAwardObject" class and instead considers "postAward" objects as documents for the eOrdering, eCatalogue, and eFulfilment modules, at least for now. Further discussion is required for the eOrdering module.

    • The proposal is to consider po-ord:OrderResponse as the type of epo-ord:Order, but further discussion is required.

  • The WG approved to Remove "epo-cat:hasExternalSpecification" property in the "epo-cat:item" in Catalogue class

  • The WG has agreed upon the use of 'epo' as the standardized namespace prefix in the ePO model.

8Bs01oDOcG8HcAAAAASUVORK5CYII=

  • The WG has approved changing from 'epo-cat:ItemDescription' to 'epo:ItemProperty', but we need to check the inheritance with 'epo-elementDescription'.

  • Discuss aligning VAT and other tax categories between modules.

    • Change the property from "epo-ful:hasBaseAmount" to "epo:isCalculatedOn" in both "epo-ord:AllowanceChargeInformation" and "epo-ord:TaxInformation".

lypQMNnN7v8AAAAASUVORK5CYII=

  • Allowance Charge Information and related information to be discussed later

    • epo-ord:AllowanceChargeInformation epo-ord:LineAllowanceInformation, ord:LineChargeInformation at line and header level

    • epo-ord:PriceDiscountInformation in price level.

Z

  • The WG approved that "epo:Contractor" and "epo-ord:Seller" are the same for all modules. However, it still needs to be determined how to incorporate this into the model."

The WG discussed the Difference between epo:hasManufacturerItemID and epo:hasSerialID​

  • Manufacturer Item Id is the Identifier of item in manufacture side.

  • Serial Id is the Identifier of instance of item.

  • The WG proposed to have epo:hasBatchId in item instance level.

9k=

  • The WG discussed the need for parties to have authorization.

    • The WG has approved the proposal to have a certificate for organizations, but further discussion is needed for Items.

  • Discuss Removing epo-ord:DeliveryTerm​

    • We should keep DeliveryTerm in contract

    • For eOrdering: we should consider the following diagram

    • epo:hasGeneralDeliveryTerm​, epo:hasDeliveryTermDescription​ ​ properties will be added to epo-ord:DeliveryInformation

    • epo:specifiesDeliveryTermLocation​ relatin will be added between epo-ord:DeliveryInformation and dct:Location

    • epo-ord:DeliveryTerm needs further discussion.

9k=

Action points:

  • The WG has approved changing from 'epo-cat:ItemDescription' to 'epo:ItemProperty', but we need to check the inheritance with 'epo-elementDescription'.

  • Change the property from "epo-ful:hasBaseAmount" to "epo:isCalculatedOn" in both "epo-ord:AllowanceChargeInformation" and "epo-ord:TaxInformation".

  • Create a diagram for Allowance Charge Information and related information

  • Draw tables for all terms and definitions for Batch, Item, Identifier.

Working Group meeting

Date: 25/04/2023
Participants: Natalie Muric, Veit Jahns
Model editor: Andreea Pasăre
Note editor: Jana Ahmad

Agenda

Goal: Discuss the current status and any potential improvements/harmonisations needed for the eCatalogue, eFulfilment, and eOrdering modules.

  • Discuss removing "postAward" objects and considering them as a document.

  • Also, consider "epo-cat:announcesPostAwardObject."

  • Revise "epo-cat:hasExternalSpecification" property in the "epo-cat:item" object and consider deleting it since we have added "epo-cat:hasExternalSpecification" association between "epo-cat:Item" and "epo:Document."

  • Change eCat:Item to epo:Item

  • Discuss adopting "epo" as a uniform namespace prefix in the ePO model.

  • Revise the naming of "epo-cat:ItemDescription" to align it between modules.

  • Discuss aligning VAT and other tax categories between modules.

  • Propose using "TaxInformation" instead of "hasVATRate" and "hasVATCategory."

  • What is the difference between TaxInformationSchema and TaxInformation?

  • Discuss if "epo-ord:PriceDiscountInformation" and "epo-cat:ChargeInformation" are the same and align them across modules.

  • Propose changing "epo-cat:specifiesItem" to "epo:specifiesDeliverable."

  • Propose adopting "epo-cat:Deliverable" into all modules.

  • Discuss the difference between "epo:Contractor" and "epo-ord:Seller" for all modules.

  • Decide whether "epo:hasSerialID" should be at the Item level or the Batch level.

  • A party should have authorization. This needs to be modeled. Take into account the Certificate as well.

  • Discuss epo-ord:TaxInformation definition.

  • Discuss removing epo-ord:DeliveryTerm.

Discussion:

  • The WG Discussed removing "postAward" objects and considering them as documents, and also consider removing the 'epo-cat:announcesPostAwardObject' relation in the following modules.

    • ​ eNotice ​​

    • eOrdering ​​

    • eCatalogue ​​

    • eFulfilment

txIAcH9iivgBAABOAgIIAAAAAAAIPQIIAAAAAAAIPQIIAAAAAAAIPQIIAAAAAAAIvUcim+sCAAAAAAAQZgQQAAAAAAAQegQQAAAAAAAQegQQAAAAAAAQegQQAAAAAAAQegQQAAAAAAAQegQQAAAAAAAQegQQAAAAAAAQegQQAAAAAAAQegQQAAAAAAAQegQQAAAAAAAQegQQAAAAAAAQegQQAAAAAAAQegQQAAAAAAAQegQQAAAAAAAQegQQAAAAAAAQev8HU+pY4brTeroAAAAASUVORK5CYII=

  • The definition of epo-cat:Catalogue is changed to: A Document describing a set of Items offered for purchase that can be processed in an electronic way.

  • It is noted that Catalogue is part of the Contract

  • The WG approved to Remove "epo-cat:hasExternalSpecification" property in the "epo-cat:item" in Catalogue class

EFAHPJAAAAABJRU5ErkJggg==

  • The WG has agreed upon the use of 'epo' as the standardized namespace prefix in the ePO model.

8Bs01oDOcG8HcAAAAASUVORK5CYII=

  • The WG has proposed a change from 'epo-cat:ItemDescription' to 'epo-cat:ItemProperty'.

UcdpdFAINQAwAAwCDUAAAAMAg1AAAADAHlRtsrHoRAVgAAAABJRU5ErkJggg==

  • Should we retain both 'epo-cat:ChargeInformation' and 'epo-ord:PriceDiscountInformation', or are they identical in meaning?

    • The WG discussed the validity or appropriateness of using "epo-ord:PriceDiscountInformation" in the context of epo-cat:Price level.

      • The WG has agreed to keep 'epo-ord:PriceDiscountInformation' as part of the 'epo-cat:Price' level.

    • The WG deliberated on whether epo-cat:ChargeInformation aligns with the "epo-cat:Price" or "epo-cat:Line or epo-cat:Item level components.

      • The WG is considering the possibility of moving 'TaxInformation' to 'epo-cat:Item', but further investigation is required

LhQcEQRBEARBEARBEARBEEr+P56Ja0g4FqdaAAAAAElFTkSuQmCC

  • The WG has agreed to the proposal of using 'TaxInformation' as an alternative to 'hasVATRate' and 'hasVATCategory'.

CTzbI9ZDpxUAAAAASUVORK5CYII=

  • The WG has reached an agreement to eliminate 'epo-cat:specifiesItem' between 'epo-cat:Item' and 'epo:Deliverable', and to consider 'epo:Deliverable' as a type of 'epo-cat:Item'.

ViVpFgEAs2f4AgAAACBLhi8AAAAAsmT4AgAAACBLhi8AAAAAsmT4AgAAACBLhi8AAAAAsmT4AgAAACBLhi8AAAAAsmT4AgAAACBLhi8AAAAAsmT4AgAAACBLhi8AAAAAsmT4AgAAACBLhi8AAAAAsmT4AgAAACBLhi8AAAAAsmT4AgAAACBLhi8AAAAAsmT4AgAAACBLhi8AAAAAsmT4AgAAACBLhi8AAAAAsmT4AgAAACBLteFLkiRJkiRJyqWxf2Lk8ToXvWdeAAAAAElFTkSuQmCC

  • The WG discussed the optimal location of 'epo:hasSerialID' at Item or Batch Level.

    • The WG has proposed to remove epo:hasSerialID and use epo:hasManufacturerItemID.

qNkjHFuAAAAAFf5jpK1Vsw5zw0AAADgKr33ePbeUWuN1pokSZIkSdK1lVLiBSRS2Dp6OHWhAAAAAElFTkSuQmCC

  • The definition of epo-ord:TaxInformation is changed to Information about the imposition of mandatory levies required by law.

Action Points:

  • Replace 'epo-ord:concludesContract' between 'epo:Contract' and 'epo-ord:OrderResponse' with 'epo-ord:implementsContract'.

P+nGxgblJGB6gAAAABJRU5ErkJggg==

  • We need to create a model that encompasses all the documents that form part of the Contract.

  • Revise 'Deliverable' in the context of eContract

Working Group meeting

Date: 11/04/2023
Participants: Natalie Muric, Sellitto Giovanni Paolo
Model editor: Andreea Pasăre
Note editor: Jana Ahmad

Agenda

Continue discussing 1st draft of eContract Model with respect to the initial contract information requirements.

  • To continue from Award of the contract

Discussion

The WG continued to discuss and model the Award of the Contract in the eContract module, specifically in relation to the requirements for initial contract information. Our methodology involves assessing whether the following requirements are already covered by ePO. If they are, the working group will map them to ePO. If they are not covered, they will be implemented as follows. The bullet points represent the initial contract information requirements, while the sub-bullets indicate their mapping to ePO.

Award of the contract

  • Award identifier:

    • adms:identifier of the epo:AwardDecision

  • Award date

    • epo:hasAwardDecisionDate (type is changed to xsd:dateTime)

  • Award time

    • epo:hasAwardDecisionDate (type is changed to xsd:dateTime)

314dlAAAgAAM7N9axKeLcAfLMIMEgGCQABAMEgCCQQJAMEgACAYJAMEgASAYJAAEgwSAYJAAEAwSAIJBAkAwSAAIBgkA4Q1SkiRdawBf+WWwbSf+DwAAAABJRU5ErkJggg==

  • Winner economic operator

    • epo:Winner

  • Economic operator name

    • dct:title on the foaf:Agent

  • Economic operator identifier

    • epo:hasRegistrationCountry from org:Organization to at-voc:country

JXAAAAAElFTkSuQmCC

  • Documents

    • epo:Contract epo:associatedWith epo:Document

  • Attachment identifier

    • adms:identifier on epo:Document

  • Attachment description code

    • At-voc-new:document-type

  • Attached document

    • we do not provide the binary object, only URL (epo:hasAccessURL on the epo:Document)

YAAAAASUVORK5CYII=

  • Deliverable offered

    • epo:specifiesDeliverable epo:Item

  • Deliverable name

    • dct:title on the epo:Item

  • Deliverable description

    • dct:description on the epo:Item

  • Delivered quantity

    • epo-cat:hasQuantity from epo:Deliverable to epo:Quantity

v9UEkII6T0AAAAAAADw64CII4SQ31gAAAAAAADg12FkRRwAAAAAAAAAAMAogYgDAAAAAAAAAAAYAog4AAAAAAAAAACAIYCIAwAAAAAAAAAAGAKIOAAAAAAAAAAAgCGAiAMAAAAAAAAAABgCiDgAAAAAAAAAAIAhgIgDAAAAAAAAAAAYAog4AAAAAAAAAACAIYCIAwAAAAAAAAAAGAKIOAAAAAAAAAAAgCGAiAMAAAAAAAAAABgCiDgAAAAAAAAAAIAhgIgDAAAAAAAAAAAYAog4AAAAAAAAAACAIYCIAwAAAAAAAAAAGAKIOAAAAAAAAAAAgCGAiAMAAAAAAAAAABgCiDgAAAAAAAAAAIAhgIgDAAAAAAAAAAAYAog4AAAAAAAAAACAIYCIAwAAAAAAAAAAGAKIOAAAAAAAAAAAgCEQiDhCCCGEEEIIIYQQQsjg8v8Bm7AYG5PqRrMAAAAASUVORK5CYII=

  • Deliverable total amount:

    • epo:hasContractValue relation is created between epo:Contract and epo:MonetaryValue

y1xItra7zVrAAAAAElFTkSuQmCC

  • epo-con:ContractAmendment object is created with:

    • epo:emendsContract relation with epo:Contract.

    • epo:hasContractAmendmentDate property.

    • epo:providesUpdatedContractValue relation with epo:MonetaryValue

    • epo:hasContractAmendment relation with epo:Contract

mEwuQAAAABJRU5ErkJggg==

  • Contract Roles class is created to specify all roles that participant in Contact

x9QunatetNeMgAAAABJRU5ErkJggg==

Action:

  • Change xsd:date to xsd:dateTime.

  • proposal to adopt epo-cat:Deliverable into all modules

  • What’s the difference between a epo:Contractor and a epo-ord:Seller for all modules?

Working Group meeting

Date: 04/04/2023
Participants: Natalie Muric, Sellitto Giovanni Paolo
Model editor: Andreea Pasăre
Note editor: Jana Ahmad

Agenda

Present 1st draft of eContract Model

Discussion

The WG revised the order, catalogue, fulfilment modules from the document level perspective.
The WG continued to discuss and model the eContract module, specifically in relation to the requirements for initial contract information. Our methodology involves assessing whether the following requirements are already covered by ePO. If they are, the working group will map them to ePO. If they are not covered, they will be implemented as follows. The bullet points represent the initial contract information requirements, while the sub-bullets indicate their mapping to ePO.

The WG decided to consider Contract as a Document

  • Legal references:

    • epo:haslegalBasis

    • epo:hasLegalReferenceDescription is added

8xR1ig1HoAAAAASUVORK5CYII=

  • Award criterion type:

    • epo:Lot specifies Procurement Criterion (epo:specifiesProcurementCriterion) epo:AwardCriterion

E582BQgSV9EAAAAASUVORK5CYII=

  • Criterion sandbox is created to clarify the relationship between procedure, lot, criterion, at-voc:legal-basis. at-voc:legal-basis, epo:legal-regime are moved to epo:ProcurementObject

N83FejvPnZHbHeeHITkEWAACAqSfIAq378vz5GOrMdMwrL78syAIAADC1BFlgImRRNtspW062i9KsvqnGWEEWAACAaSTIAhOpGu3M6h0AAACYNoIsMJHScGdW5wAAAMC0EWQBAAAAAJaJIAsAAAAAsEwEWQAAAACAZSLIAgAAAAAsE0EWAAAAAGCZCLIAAAAAAMtEkAUAAAAAWCaCLAAAAADAMhFkAQAAAACWiSALAAAAALBMBFkAAAAAgGUiyAIAAAAALBNBFgAAAABgmQiyAAAAAADLRJAFAAAAAFgmgiwAAAAAwDIRZAEAAAAAlokgCwAAAACwTARZAAAAAIBlIsgCAAAAACwTQRYAAAAAYJkIsgAAAAAAy0SQBQAAAABYJrUga4wxxhhjjDHGGGOMMebnnf8PeALKnEIySoMAAAAASUVORK5CYII=

  • epo:PlannedProcurementPart is not epo:ProcurementObject.

  • epo:foreseesProcurementObject relation is added between epo:PlannedProcurementPart and epo:ProcurementObject.

5AAAAAElFTkSuQmCC

  • Tender identifier

    • epo:includesTender from epo:Contract to epo:Tender

    • epo:hasLotReference

AU8anzJkbNtIAAAAAElFTkSuQmCC

  • Tender digest

    • epo:hasElectronicDigest relation is created between documents.

  • Tender signature

    • epo:ElectronicSignature object is created with epo:hasElectronicSignature relation to epo:Document.

    • dct:description property is added to epo:ElectronicSignature object

YNEAAAAASUVORK5CYII=

  • Tender total amount:

    • epo-ord:hasTotalTaxInclusiveAmount

AU5nlhNCPPpbAAAAAElFTkSuQmCC

  • Tender total tax amount:

    • epo-ord:TaxInformation Action:

  • Map contract, document wrt top level ontology

  • To move from epo:ProcurementElement the following suggested documents:

    • Tender

    • AwardDecision

    • ReviewObject

  • Discuss Tender total tax amount and Tender total amount from initial contract information requirements.

Working Group meeting

Date: 21/03/2023
Participants: Natalie Muric, Wim Kok, Giampaolo Sellitto
Model editor: Andreea Pasăre
Note editor: Jana Ahmad

Agenda

Discuss eContract Model.

Discussion:

WG discussed the eContract model, mainly the initial contract information requirements:

  • epo-con: announces contract exists between epo:Contract and epo-con:ContractDocument. It was noted that Contract document is not a contract, it is maybe some additional things such as metadata. What is in the contract is in the contract document.

H+Qri3rBgJ0OQAAAABJRU5ErkJggg==

  • An Excel document is created in sharepoint including Contract related concepts and their definitions.

  • epo:bindsBuyer relation created between contract and Buyer.

  • epo:signedByBuyer relation is created between Buyer and contractDocument

MkQIIWUNAAAAwERB1gghZAoDAAAAMFFmrKwBAAAAAADMZpA1AAAAAACAEoKsAQAAAAAAlBBkDQAAAAAAoIQgawAAAAAAACUEWQMAAAAAACghyBoAAAAAAEAJQdYAAAAAAABKCLIGAAAAAABQQpA1AAAAAACAEoKsAQAAAAAAlBBkDQAAAAAAoIQgawAAAAAAACUEWQMAAAAAACghyBoAAAAAAEAJQdYAAAAAAABKCLIGAAAAAABQQpA1AAAAAACAEoKsAQAAAAAAlBBkDQAAAAAAoIQgawAAAAAAACUEWQMAAAAAACghyBoAAAAAAEAJSckaIYQQQgghhJDy5P8DgXtJdNJU2u8AAAAASUVORK5CYII=

WG did a Mapping between Contract model and initial contract information requirements:

  • Issue date, time and identifies should be in the document

  • isSubjectToContractSpecificTerm relation is created between contract and ContractTerm

D3XsGG8jHLzNAAAAAElFTkSuQmCC

  • Procurement project type: is contract-nature on ContractTerm

  • Description of Extension and option: epo:ContractTerm has epo:hasOptionsDescription data property. Duration is considered to be about Options.

  • Period start date, Period start time: contractTerm defines the contract period.

9OqYBAAABGObfNTf87GqTiRgAJMwHAACQMB8AAEDCfAAAAAnzAQAAJMwHAACQMB8AAEDCfAAAAAnzAQAAJMwHAACQMB8AAEDCfAAAAAnzAQAAJMwHAACQMB8AAEBizYckSZIkvXaPBAAA4MMA6G7xx+EI53QAAAAASUVORK5CYII=

  • qt-voc:cpvsuppl is removed

  • CPV: at-voc:cpv enumeration is added.

8PiEkAjCVLt3kAAAAASUVORK5CYII=

  • CPV supplementary: is not included in ePO

  • Project execution location: epo:ContractTerm defines place of performance which is dct:location

zze2nXfUdus77Bt2nYw2n7b8dOeQFOEQAMAAFDQ99dXO9xtNzafTgWa5AQaAACAojaRZvNJ87vNl4XV2zDOCDR5CTQAAAA7YnjEW92Rk0ADAACwI8aHvNUcOQk0AAAAAMEEGgAAAIBgAg0AAABAMIEGAAAAIJhAAwAAABBMoAEAAAAIJtAAAAAABBNoAAAAAIIJNAAAAADBBBoAAACAYAINAAAAQDCBBgAAACCYQAMAAAAQTKABAAAACCbQAAAAAAQTaAAAAACCCTQAAAAAwQQaAAAAgGACDQAAAEAwgQYAAAAgmEADAAAAEEygAQAAAAgm0AAAAAAE2wo0ZmZmZmZmZmYWsx8jgDZQhaLbbAAAAABJRU5ErkJggg==

  • Procurement project lot: Contract and lot class is created.

AWE4I0qJn19yAAAAAElFTkSuQmCC

  • Lot identifier:

    • epo:hasTenderReference relation is renamed between contract and tender.

    • epo:hasLotReference relation is renamed between contract and lot.

YguADCE9IW2Ma0BAOhHdAEAAACogOgCAAAAUAHRBQAAAKACogsAAABABUQXAAAAgAqILgAAAAAVEF0AAAAAKiC6AAAAAFRAdAEAAACogOgCAAAAUAHRBQAAAKACogsAAABABUQXAAAAgAqILgAAAAAVEF0AAAAAKiC6AAAAAFRAdAEAAACogOgCAAAAUAHRBQAAAKACogsAAABABUQXAAAAgAqILgAAAAAVEF0AAAAAKtAVXYwxxhhjjDHGGGNMORP9H5My6HZhnaeQAAAAAElFTkSuQmCC

Working Group meeting

Date: 28/02/2023
Participants: Ahmed Abid, Wim Kok, Natalie Muric, Csongor Nyulas, Sellitto Giovanni Paolo
Model editor: Andreea Pasăre, Eugen Costetchi
Note editor: Jana Ahmad

Agenda

  • Standard form mapping issues (ePO repository):

  • Continue discussing Procedure and sub-procedure

Discussion

GH 370

  • To be closed only after we get confirmation that (and perhaps a link to) an issue asking for the introduction of appropriate code(s) in the at-voc:direct-award-justification vocabulary was opened with DG GROW.

GH 431

  • hasRestatedAwardedValue: This is wrongly modeled and applied in the mappings. It will be updated in the context of modeling eContract. To be discussed in RDF meeting

Procedure and sub-procedure:

  • WG decided to:

    • Separate a procedure from its scope

    • Drop down plan into its phases.

  • Notes from WG:

    • Procedure itself is a plan.

    • It is not correct to use process concept to refer to plan/procedure.

    • Nothing is to be executed in procedure, it is just a plan

    • Lot is referring to purpose.

  • Plan hierarchy model

    • Lot is procurementScope not a ProcurementObject

ZG30G+s0fi4AAAAASUVORK5CYII=

  • SelectioCriteria and ExclusionGround are specified for LotQualificationPhase

4ucgAAAABJRU5ErkJggg==

  • Lot Plan composition model contains the phases/stages of procurement lifecycle

wNEBeBlVecdTQAAAABJRU5ErkJggg==

  • Overall plan composition model

xe8vtdWexvDhAAAAABJRU5ErkJggg==

  • Note, if we have hundreds of lots and anything is applied to one lot it will be applied to all lots in the same procedure (to be discussed later).

  • We should find a better term than LotPreAwardLifecycle/Workflow.

KAAAAAElFTkSuQmCC

Working Group meeting

Date: 07/02/2023
Participants: Jana Ahmad, Natalie Muric, Csongor Nyulas
Model editor: Andreea Pasăre
Note editor: Eugeniu Costetchi

Agenda

  • Standard form mappings - ePO GitHub issues:

    • GH 422 Missing fields F21, IV.2.5, IV.2.9

  • Procedure/Sub-procedure

Discussion

GH 442

In the context of concession contracts, the award of procedure actually means procedure. So the “scheduled date for start of award of procedure” is the start of the procedure. We should look into the Directive 2014/24/EU for a better understanding.

kGQFQEJNz8nPl87H35Xvry2RWdYOsa90vdTVpaaht1o0mFA28AK9FeCO8RdoTOYwBwnxAZwKtBPEkFQFhoLz+Z8LHYRP9IiBDqEPO+6QhEgHhiERAJAJCEYmA7IhEQHZEIqAzIhFwcEQiIDvCRIB7ER7tpbu8pU4ckk1N0lwv8sIHNfLZvCLpGsuTr+TnyFP7D0jePpEDuz+UmtY2Id5fUZ9WEcD3ZCcRQP143rDdJzj1RcCJQCQCwhGJgHAciQj4f1HoSUhCBZdkAAAAAElFTkSuQmCC

Procedure versus sub-procedure

The term procedure has been conflated.
Question: What is a procedure?
Answer: A description of steps taken by someone, a plan.
This plan acts as a general plan for multiple Lots. There are specific plans per each Lot, but the general plan should be fine-tuned in order to cover all the Lots.

Within a procurement project we can have a procedure type. Each lot should be executed once or multiple times according to the procedure type.

There are procedural things that are open to all Lots. We can think about it as a procurement procedure.

Some actions/events are reusable within a procedure:

  • Buyer calls for competition [object] (publish Competition Notice)

  • Buyer awards [object] (and publish a Contract Award Notice)

  • Buyer (re-)opens a (mini-)competition [object]

The negotiation action can be part of the competition.

Also, WG discussed re-usable process fragments:

  • Qualification (exclusion grounds and selection criteria)

  • Competition

eAuction and mini competitions are subsets of closed competition.

Some important examples of procedure types are discussed:

  • Restricted procedure:

    • Buyer calls for competition [specific-object] (Competition Notice)

    • Qualification

    • Closed-Competition [specific-object]

    • Buyer awards [specific-object] (Contract Award Notice)

  • Restricted procedure with eAuction

  • Restricted procedure with Dynamic Purchasing System

The competition is related to award criteria and the qualification is related to exclusion grounds and selection criteria. All the process fragments should take into consideration the criteria and the appropriate objects.

Plan versus execution

A differentiation between a plan and an execution is discussed.

  • A Plan (~Procedure + Lots) is a detailed proposal for doing or achieving something.

    • Goal: award of a contract

  • An *Execution (~ProcedureExecution) *represents the carrying out of a plan, order or course of actions.

    • Achievement: award of a specific contract.

    • We can have procedure executions per Lot (for a Lot there may be one or multiple executions)

We can have procedure-executions per Lot. For a lot, there may be one or multiple executions.

There is one execution for the whole procedure.

  • Each lot has one or multiple procedure executions within the “frame” of the “Procedure” execution.

Procurement purpose is split into Lots, and NOT the procedure that is split into lots.

Working Group meeting

Date: 31/01/2023
Participants: Jana Ahmad, Laszlo Ketszeri, Natalie Muric, Csongor Nyulas, Giampaolo Sellito, Marc Christopher
Model editor: Eugeniu Costetchi
Note editor: Andreea Pasăre

Agenda

Discussion

 The WG discussed:
Candidate role: This role exists in ePO version 2.0.2 as epo:CandidateShortList have the following definition: “The tenderers that have been selected in a two stage procedure.

Additional information: the types of procedures that this shortlist applies to are restricted procedures, competitive procedures with negotiation, competitive dialogue procedures and innovation partnerships. The WG approved the previous definition and additional information on (WG 27/07/2018).

epo:EconomicOperatorShortList is a superclass for CandidateShortList. This concept has the following definition: “The Economic Operators that are considered for a given procedure”. The WG approved the previous definition on (WG 22/08/2019).

A new role was added for the next ePO release, epo:Candidate, with the following definition: “The role of an agent that has expressed interest to participate in a competition. The WG approved the previous on (WG 31/01/2023).

AeV4Y0xawEbDAAAAAElFTkSuQmCC

The concept is a subclass of epo:OfferingParty as depicted in the diagram below:

S6V5eu0PpfGwYYpAAAA+kKYAgAAIAJhCgAAgAiEKQAAACIQpgAAAIhAmAIAACACYQoAAIAIhCkAAAAiEKYAAACIQJgCAAAgAmEKAACACIQpAAAAIhCmAAAAiECYAgAAIAJhCgAAgAiEKQAAACIQpgAAAIhAmAIAACACYQoAAIAIhCkAAAAiEKYAAACIQJgCAAAgAmEKAACACPbC1MzMzMys5f4GOexIC6835HUAAAAASUVORK5CYII=

Buyer role refinement: The buyer may need to be further refined into AwardingBuyer and AcquiringBuyer, similarly as it is done for the CPB.

GH 421:

Section III.1.* of F21 refers to Selection criteria.

HzFPOdTmrzMAAAAASUVORK5CYII=

  • Section III.1.4: Objective rules and criteria for participation refers to description in requirement.

GueAWkzHbPQAAAABJRU5ErkJggg==

  • Codelist to be used in at-voc-applicability.

  • epo:hasreservedProcrument added to ParticipationCondition.

ASzHnvI7pjzJAAAAAElFTkSuQmCC

  • epo:hasReservedExcution added to ContractTerm Section III.2. *“contract performance conditions” refers to ContractTerms.

PMUZ5VdCXgeiFC8T6n1dbi3T0f4qpZMkckqaYXcD6EVn4DgC3fDscsySJsY5LcYy8W5YWSlWvwo7lvKG+TivGInNThNLrZUvocl+BdYdRN4cd0ciQAAAABJRU5ErkJggg==

In the eForms they are at the Lot level, but in the standard forms they are at the Procedure level? They are in fact “criteria summaries” for Procedure level

  • Section III.2.1: information about a particular profession refers to ContractTerms

564EHAIYZeAAIZOABIJCBB4BABh4AAhl4AAhk4AEgkIEHgEAGHgACGXgACGTgASCQgQeAQAYeAAIZeAAIZOABIJCBB4BABh4AAhl4AAhk4AEgkIEHgEAGHgACGXgACGTgASBQb+AlSVJGj4EHALJcATl+tXZ9p8jJAAAAAElFTkSuQmCC

  • information about a particular profession should be mapped to selection criteria summary:

  • In selectionCriteriasummary object two properties are added

  • Eop:hasProfessionRelevantLaw

  • epo:isReservedToParticularProfession

aD8DenYVbOEAAAAASUVORK5CYII=

  • BT-79 - III.2.3 - information about staff responsible for the performance of the contract

  • isResponsibleStaffNameIsrequired property is created in ProcrumentCriteriasummary object

x8dTj+x4oGrQgAAAABJRU5ErkJggg==

  • Two enumerations are added to SelectionCriterien object

EGcYZmSD1kMIA0BB2f8hzjDMyAathxAGAABAIRHCAAAAKCRCGAAAAIVECAMAAKCQCGEAAAAUEiEMAACAQiKEAQAAUEiEMAAAAAqJEAYAAEAhEcIAAAAoJEIYAAAAhUQIAwAAoJAIYQAAABQSIQwAAIBCIoQBAABQSIQwAAAACokQBgAAQCERwgAAACgkQhgAAACFRAgDAACgkAhhAAAAFBIhDAAAgEKKhTDDMAzDMAzDFGrsOgYAAACK4P8DGGgQKQ6Ki9kAAAAASUVORK5CYII=

  • epo:hasPerformingStaffQualificationInformation is added to epo:ProcurementCriterien

Dz89azE4PiLnAAAAAElFTkSuQmCC

Question: Does SelectioncriteriaSummary inherit from SelectionCriterien?

  • Yes, So then, ProcrumentCriteriaSummary inherits from ProcrumentCriterien.

  • To be checked, when reworking on the Criteria & Criteria Summary: if epo:isReservedToParticularProfession: is the same as the one in the epo:ContractTerm.

AeV4Y0xawEbDAAAAAElFTkSuQmCC

Working Group meeting

Date: 24/01/2023
Participants: Jana Ahmad, Laszlo Ketszeri,, Natalie Muric, Csongor Nyulas, Giampaolo Sellito
Model editor: Andreea Pasăre
Note editor: Eugeniu Costetchi

Agenda

Discuss github following issues:

  • Standard form mappings - TED-SWS github issues:

  • Standard form mappings - ePO github issues:

Discussion

GH 119

  • When we have missing mapping in the technical mapping but the data exists in the standard forms, then we should add the remark in the RDF output as a rdfs:comment. ==== GH 418

  • The generalisation statement between a role and its type (AcquiringParty, SellerParty or AuxiliaryParty) should not be present in the technical mapping.

  • This ticket and https://github.com/OP-TED/ted-rdf-mapping/issues/289 were closed, with the same resolution.

3mAMQLGv5mEAAAAASUVORK5CYII=

GH 419

The property epo:hasLotAwardLimit has been deleted.

ecfgQcWzhmwAAAABJRU5ErkJggg==

epo:hasMaximumNumberOfLotsToBeAwarded is kept.

GH 420

  • In the standard form, we have just generalised information (generalisation criterion) at the procedure level.

  • And the procurement criteria is specified for the lot level .

  • In the standard form, procedure specifies criteria summary (so we can have summary criterion at the procedure level .).

  • We should differentiate between criteria and criteria summary

  • Create participation criterion class in a lot level (so we have 4 criteria now).

  • Participation is at the submission level.

  • Participation conditions should be even before submission

  • Two approaches for Criteria modelling (concept and instance diagrams) have been presented and are depicted below.

Example 1

yIR40IZYXGeAAAAAElFTkSuQmCC
w7EgibL+4XIAQAAABSCyAEAAAAUgsgBAAAAFILIAQAAABSCyAEAAAAUgsgBAAAAFILIAQAAABSCyAEAAAAUgsgBAAAAFILIAQAAABSCyAEAAAAUgsgBAAAAFILIAQAAABSCyAEAAAAUwifLC09Co9Wnh4tXBgAAAMgLkQMAAAAoBJEDAAAAKASRAwAAACgEkQMAAAAohI4iRzwWAAAAIC9EDgAAAKAQRA4AAACgEEQOAAAAoBBEDgAAAKAQRA4AAACgEEQOAAAAoBBEDgAAAKAQRA4AAACgEEQOAAAAoBBEDgAAAKAQRA4AAACgEEQOAAAAoBBEDgAAAKAQRA4AAACgEEQOAAAAoBD+H4fyFIxTZr5jAAAAAElFTkSuQmCC

Example 2

8BBMyJXFrigRQAAAAASUVORK5CYII=
P+SOUqRgPVgAAAABJRU5ErkJggg==

  • Submission terms:

    • Submission terms: rules for submission

    • Submission terms has participation condition

    • Participation conditions had reserved procurement.

hHAAAAEgIwjkAAACQEIRzAAAAICEI5wAAAECCEM4BAACAhCCcAwAAAAlBOAcAAAAS4n9cFkMmx2ncXgAAAABJRU5ErkJggg==
PamR385hDfvdQlRteclSay5helviHCO3HCKMI7vNANopN7G5vYYfX1WA1WgTxo2ySIG5SudziQXBYGlkUl45YOJJCXuclf9b27ZIM7q0tY399RUUV+b3ELfWOIrG6ROVqQb2fqN5RXOao9SxJojawjVES9xePfoygcrdLn3dWaLuKaIciittUjraoDG0teo846nJKUsiDIW3MukkQWRQ92OAld0UVSRS+MP8XtSKteqKGCrgAAAAASUVORK5CYII=

  • Create criteria summary diagram to differentiate between procurement criteria and procurement criteria summary:

    • If the procurement criteria goes to the procurement object, Ground exclusion is the same for all lots.

    • Giampaolo suggests adding relation between Selection Criteria and Selection Criteria Summary (aggregation relation).

  • Decided to model the following:

+3YMQ0AIBAAMfwbJCF5LTCwnIgONVGAEOcAAAAAABDiHAAAAAAAQpwDAAAAAECIcwAAAAAAiDVnXwAAAAAA4BPnAAAAAAAQ4hwAAAAAAEKcAwAAAABAiHMAAAAAAAhxDgAAAAAAIc4BAAAAACAemscyA9xzysoAAAAASUVORK5CYII=

Working Group meeting

Date: 17/01/2023
Participants: Jana Ahmad, Natalie Muric, Pietro Palermo, Thomas Pettersson, Giampaolo Sellito, Emidio Stani, Ivan Willer
Model editor: Andreea Pasăre
Note editor: Eugeniu Costetchi

Agenda

Discussion

Core Vocabularies observations

  • epo:hasOrganisationUnit should be an attribute on the OrganisationalUnit concept from org ontology.

  • If we follow org ontology we need to add a new class where to put only an attribute for the name.

vwghhMQmNKgJIYQQQgghhBBCCCGEzAg0qAkhhBBCCCGEEEIIIYTMCDSoCSGEEEIIIYQQQgghhMwINKgJIYQQQgghhBBCCCGEzAg0qAkhhBBCCCGEEEIIIYTMCDSoCSGEEEIIIYQQQgghhMwINKgJIYQQQgghhBBCCCGEzAg0qAkhhBBCCCGEEEIIIYTMCDSoCSGEEEIIIYQQQgghhMwINKgJIYQQQgghhBBCCCGEzAg0qAkhhBBCCCGEEEIIIYTMCDSoCSGEEEIIIYQQQgghhMwINKgJIYQQQgghhBBCCCGEzAg0qAkhhBBCCCGEEEIIIYTMCP8PVFhkCPTdwgcAAAAASUVORK5CYII=

  • The reason why we conflated these two is the case when only a particular unit is the Buyer.

  • Recommendation to not separate these two concepts (Organisation and Organisation Unit) and only rename the attribute to epo:hasOrganisationUnitName

    • Why? Because the Agent that takes a role (e.g. Buyer) can be a Unit or an organisation, but we decided to set the description at the “organisation level”.

  • epo:hasLegalFormType - from SEMIC perspective we asked the OP to create the Core Vocabulary for the classification of the legal forms from GLEIF:

    • This will be published in the future.

    • Switch to using a code list for legal type classifications.

cv:LegalEntity versus epo:Business

Definition for cv:LegalEntity:
A self-empoyed person, company, or organization that has legal rights and obligations.

QvHjpz8SADDJIpUPQKdeSLbb+PGoc8SP8xYAgOktUvnwPE++rqTnRQEpahvitFdLCRdfAGB6i1Q+AADADwDlAwAAaEX5AAAAWlE+AACAVpQPAACgFeUDAABoRfkAAABaUT4AAIBWlA8AAKAV5QMAAGhF+QAAAFpRPgAAgFaUDwAAoBXlAwAAaEX5AAAAWlE+AACAVpQPAACgFeUDAABoRfkAAABaUT4AAIBWlA8AAKAV5QMAAGhF+QAAAFpRPgAAgFaUDwAAoBXlAwAAaEX5AAAAWlE+AACAVpQPAACgFeUDAABoRfkAAABaUT4AAIBWlA8AAKAV5QMAAGhF+QAAAFpRPgAAgFaUDwAAoBXlAwAAaEX5AAAAWlE+AACAVpQPAACgFeUDAABoRfkAAABaUT4AAIBWlA8AAKAV5QMAAGhF+QAAAFpRPgAAgFZvUj7OnTsny0dw8j1ydwAAADBBt9sVbcGyLNklgtgsRmRi+UgkEq7r2rYtRnlEfPOAyQ8AADBZvGpcuHBBFAnf9x3HiT1kcvmQbUUSnaPZbMa+CAAAMJ7neUHYQkSXkJddRkwsH5cvX5YbrVYrOmiaZrQNAAAwQjSPXq8n+4ecyHBdd9qZj0Qikc1mo135LIIPAAAwQdQcjo6OLl68KPpDtH4jMrF8iLaSSqXOKX4EAAAwwfnz52VhuHTpUiKRqNVqQWwK47hjxHfiHMfpdDrxI9ElHAAAgLGiX5UVDMN4VSNiJpaP4GS1h23b8hdmgvCyzfceAQAAoBAVIuoM9Xr9+188tXwAAAC8dZQPAACgFeUDAABoRfkAAABaUT4AAIBW3wH6TmFMOlTauAAAAABJRU5ErkJggg==

Definition for epo:Business:
A private law company registered in a national registry.

VKarBkAAAAAElFTkSuQmCC

  • epo:Business should be a subclass of cv:LegalEntity in Core Business Vocabulary.

  • In order to align with Core Voc, it means we need to add cv:LegalEntity and org:FormalOrganization between org:Organization and epo:Business.

  • But a Business has to be a FormalOrganization.

  • In CPOV, a PublicOrganisation is not org:FormalOrganisation, but it is directly under org:Organisation.

dgAAAABJRU5ErkJggg==

  • Depending on the country, a cpov:PublicOrganisation may have a legal entity, so it may be a formal organisation.

  • Hierarchy

    • Org:Organisation

      • cv:PublicOrganisation

      • org:FormalOrganisation

        • legal:LegalEntity (self-employed person, company, or organisation with certain rights)

          • Action: Replace epo:Business by cv:LegalEntity

      • epo:OrganisationGroup

  • We need to have a discussion on whether the legal form type is at the legal entity level or at the organisation level.

    • What if we have the case when a tenderer is a public organisation?

  • This relationship is used at the Organisation level because foaf:Agent includes also a person or a system.

  • Decided to remove the relation from epo:OfferingParty to epo:Business as depicted in the diagram above.

CgAAAABJRU5ErkJggg==
Concession contract

  • In CPSV-AP the cv:ServiceConcessionContract was added as a subclass of epo:ConcessionContract:

WCeQt0dpNt2GHT8UIso+CrVjketBr100+lEAjiIYzCBmEUDr7vvwlNieF+bgseAAAAAElFTkSuQmCC

  • For CPSV-AP we need a relationship between epo:Contract to epo:ContractSpecificTerm (epo:hasContractTerm) in order to be able to get to the at-voc:contract-nature:

D8MFzktkMfMkQAAAABJRU5ErkJggg==

  • Contract includes specific terms

  • Contract cannot have epo:ContractSpecificterms

  • Contract “includes Lot”, is not right, needs more discussion on this.

Order

  • Look into the syntax binding, where we will see all the “elements” that we need to see in the order.

  • For example, Contract ID, is missing, or what is in the Buyer? It is hard to see all the elements from the ePOcore or eCatalogue, or eFulfillment.

  • Request: can we have a plain table with all properties for a class (including inherited attributes).

    • Technical Question:

      • Given a UML model, can we generate an “application profile” in a tabular representation (see SKOS-AP-EU ), for each class considering also inheritance.

      • Can we also automatically generate a “Path” to get that property?

  • It was found that a epo:ProcurementElement does not have an identifier, so the relation between epo:ProcurementObject and epo:Identifier was moved from epo:ProcurementElement to epo:Identifier as depicted in the diagram below:

6v8DttBVGvFk67oAAAAASUVORK5CYII=

  • Proposal to work on a table that contains all the properties for all the concepts in the Order phase on the 26th Jan.

Working Group meeting

Date: 10/01/2023
Participants: Jana Ahmad, Vladimir Alexiev, Emiel Dhondt, Juris Kalejs, Wim Kok, Natalie Muric, Giampaolo Sellito, Emidio Stani
Model editor: Eugeniu Costetchi
Note editor: Andreea Pasăre

Agenda

  • Core Vocabularies alignment

    • observations for ePO

Discussion

Core Vocabularies observations

cpv:Person

  • data type is Changed from rdfs:Literal to rdf:langString in the following properties :

    • foaf:name

    • foaf:familyname

    • foaf:givenName

    • person:patronymicName

    • dct:alternative

  • cv:deathDate Removed from cpv:Person.

cpov:ContactPoint

  • epo:hasInternetAddress is similar to contactPage with foaf:Document as range.

  • Proposal by Core Vocabularies to change the range to anyURI so this contactPage can be adapted by ePO as well.

  • Based on the standard forms, epo:hasInternetAddress is probably the URL of the Organization and not of the ContactPoint.

wFZbNNUW1zYqQAAAABJRU5ErkJggg==

  • https://schema.org/mainEntityOfPage

  • Proposal to add epo:hasHomePage (xsd:anyURI, [0..*]) as an attribute on org:Organization concept with the following definition: “The main web page.”

cv:Channel

  • epo:hasDescription is similar to http://purl.org/dc/terms/description

  • If we change the datatype to LangString, we need to change them all.

  • rdfs:Literal allows integers, booleans and LangString, etc.

  • We need to revise data types and make them more specific.

  • Better to use rdf:PlainLiteral, see GitHub ticket: https://github.com/OP-TED/ePO/issues/405

  • Instead of epo:hasDescription switch dct:description.

  • epo:hasURL is mandatory property, but it should not be, because sometimes we might need to use epo:isAdhocChannel.

  • In standard forms AdhocChannel is not a boolean, but in eForms it is.

  • The AdhocChannel should not be CommunicationMean.

  • An Organization hasCommunicationMeans either a Channel or a DeliveryGateway.

epo:AgentInRole

  • The attribute epo:hasTitle was changed to dct:title and the definition modified accordingly.

epo:Identifier

  • WG discussed whether to use dct:identifier instead of epo:hasID.

  • But dct:identifier has a range of rdfs:Literal and can not be used.

  • We need to decide on whether to change to adms:identifier (old github issue: https://github.com/OP-TED/ePO/issues/258)

  • If we need more properties for ePO we should add a ticket to adms.

PSXdAFwygm2+8THFfROdBrjt8SHH9sAdjWhb+f0i4c7+rH638DmWMEupwuqTgAAAAASUVORK5CYII=
euBusinessGraph Semantic Data Model
pg111kJEXfh15AClteTmzQiNFvbYabXSq+OzS6vjqUDtdp0Fmrrw68gBGq0m31PHM4Ha7ToLDHXh15EDNFpNvqeOZwK123UWGOrCryMHaLSafE8dzwRqt+ssMNSFX0cO0Gg1+Z46ngnUbtdZYKgLv44coNFq8j11PBOo3a6zwFAXfh05QKPV5Hvq0KEjO+jCryMHqEW1IFCHDh3Z4f8Boy4TvokJvsUAAAAASUVORK5CYII=
dct:Location

  • locn:geographicName data type is Changed from rdfs:Literal to rdf:langString.

locn:Address

  • All attributes data types are changed from rdfs:Literal to rdf:langString, except locn:postCode and locn:locatorDesignator.

CCCEV

On cccev:Requirement:

  • cccev:description changed to dct:description (rdf:PlainLiteral).

  • cccev:identifier changed to dct:identifier.

  • We need to use an identifier for requirements.

  • To stay consistent to how identification is realised in ePO, we switched to using adms:identifier instead of dct:identifier as per CCCEV requirement.

  • Instead of cccev:name we will use skos:prefLabel (rdf:PlainLiteral).

  • There should be only one description and we added as additional information that we can have multiple languages for the same description. (see https://www.w3.org/TR/skos-reference/#L1567)

wEwgjm4sGfsyQAAAABJRU5ErkJggg==

  • On cccev:type changed to dct:type

  • On cccev:InformationConcept, hasDescription and hasTitle are changed to dct:description and skos:prefLabel.

WG disscussed the Channel

  • In standard form we have the following section for communication:

dX4ppmnn+7cAAAAASUVORK5CYII=

  • We want to use the AdhocChannel as a URL and not a boolean.

  • We might need to remove epo:hasAdditionalInformation and epo:hasName from cv:Channel.

  • In CPVS-AP, cpsv:PublicService has a cv:Channel.

  • We need to do a comparison to version ePO 2.0.1.

  • Adding epo:hasToolsAccessURL (xsd:anyURI, [0..1]) attribute to epo:AccessTerm concept with the following definition: “Web page where the tools and devices for electronic communication that are not generally available can be downloaded free of charge.”

  • This needs to be further discussed.

  • cv:Channel was moved from org:Organization level to epo:AgentInRole level.

AewJWbcIw23GQAAAABJRU5ErkJggg==

  • In PEPPOL, an endpoint is an identifier.

  • The cv:Channel class was deleted.

  • We need to further discuss the difference between epo:Business and cv:LegalEntity.